Delving into client performance.
This report was compiled with data until epoch 160 (2020-12-02 05:04:23 UTC). We look at the performance of validators who self-declared their client, either writing the client name in their graffiti or with the POAP tag.
Declared client is obtained in the graffiti of produced blocks:
poap and ends with a, b, c, d and e (respectively, Prysm, Lighthouse, Teku, Nimbus and Lodestar).teku/v20.11.1).Since the chain started recently, we do not have a lot of graffitis to scrape from. Additionally, not all graffitis feature the client name or the poap (thanks, Mr. F). This analysis is carried over self-declared clients then.
We have identified the client of 1403 validators, out of 4801 blocks produced.
We observe a lot more incorrect head attestations when the attestation is made for the starting slot of a new epoch. We name slot_index the index of the slot in the epoch (from 0 to 31).
Attesters get the head wrong whenever the block they are supposed to attest for is late, and comes much after the attestation was published. We can check which clients are producing these late blocks.
Since these late blocks seem to happen more often at the start of an epoch than at the end, it is quite clear that epoch processing is at fault, with some clients likely spending more time processing the epoch and unable to publish the block on time.
We can also check over time how the performance of validators on blocks at slot index 0 evolves, again plotting per client who is expected to produce the block at slot index 0.
In the plots below, we align on the y-axis validators activated at genesis. A point on the plot is coloured in green when the validator has managed to get their attestation included for the epoch given on the x-axis. Otherwise, the point is coloured in red. Note that we do not check for the correctness of the attestation, merely its presence in some block of the beacon chain.
The plots allow us to check when a particular client is experiencing issues, at which point some share of validators of that client will be unable to publish their attestations.
A block can include at most 128 aggregate attestations. How many aggregate attestations did each client include on average?
Smaller blocks lead to healthier network, as long as they do not leave attestations aside. We check how each client manages redundancy in the next sections.
Myopic redundant aggregates were already published, with the same attesting indices, in a previous block.
Subset aggregates are aggregates included in a block which are fully covered by another aggregate included in the same block. Namely, when aggregate 1 has attesting indices \(I\) and aggregate 2 has attesting indices \(J\), aggregate 1 is a subset aggregate when \(I \subset J\).
Lighthouse and Nimbus both score a perfect 0.
We first look at the reward rates per client since genesis.